Make collection iterators forward_iterator
* and beyond
#720
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
BEGINRELEASENOTES
forward_iterator
,bidirectional_iterator
andrandom_access_iterator
concepts. The collections can be used with more categories of range algorithms - up torandom_access_range
, for examplestd::adjacent_find
,std::lower_bound
,std::fold_right
, and more views likestd::ranges::views::reverse
ENDRELEASENOTES
Here is a proposal how to make collection iterators fulfill
std::forward_iterator
which also opens the way forstd::bidirectional_iterator
andstd::random_access_iterator
by making a single exceptionThe collection iterators fulfill all the
forward_iterator
requirements except one semantic requirement:The problem here is the
operator->
that returns a pointer to data type object that is a member of the iterator (collections store data layer objects and data type are created on-the-fly so there is no data type object with lifetime livinf inside collection to which pointer we could return). Due to this the validity of obtained pointer is as long as the iterator is valid - to fulfill the requirement it should be as long the collection is valid.In reality it's quite hard to abuse as things obtained through
->
(iterator->energy()
) are safe since they go through the data layer that lives in the collection. The problem seems to be only getting the pointer directly with pattern like this:which is rather rare in normal usage. A pattern like this
auto particle = *(iterator.operator->());
again is okay since the pointer is used immediatelyOf course the final question is whether it's used somewhere in an implementation of the std algorithms. On top of that it should be used in a certain way like creating a temporary copy of iterator, taking pointer, disposing of the copy, using iterator
In the past there were some precedence event in the standard library that iterators were assigned some category except something (that was for Legacy iterators):
TL;DR Iterators gain support up to
std::random_access_iterator
except that technically they don't meet a requirement for pointers obtained withauto* ptr = it.operator->();
pattern to outlive the iterator